在dwell，我们为物联网网关编写的代码已经用Rust了。它快速，可靠，安全。但我们不是从Rust开始的，我们也不是在一个周末就写好了代码。本系列讲述的是我们一年前的故事，我们是如何变成Rust的，以及为什么你可能想要做同样的事情。我们将介绍使用Rust的原因(或者不使用!)、线程化、硬件通信、无畏的并发、与C库交互、从头编写MQTT库，以及我们经过艰苦努力学到的经验教训。

一年前，我加入了一家物联网初创公司，当时有大量的遗留Python代码在Raspberry Pi上运行。在几年的时间里，这些代码已经有机地增长了，就像大多数代码库一样。这段代码的最初目的是监视MQTT命令通道，通过串口解码和执行Z-Wave网络上的命令，并通过另一个命令通道报告成功或失败。此外，代码还用于报告有关系统总体健康状况和Z-Wave网络上连接的设备状态的信息。在这个过程中，软件逐渐转移到控制状态led，通过单独的串口控制蜂窝调制解调器，并与板载发布管理软件进行通信。

在我的招聘面试中，一位高级软件工程师迫切地想要重写整个程序，于是我离开了一家c++商店，这家商店在之前的成功的势头下摇摇欲动。剧透:他想把现有的Python代码转换成Rust，这个前景非常令人兴奋，我从我的旧工作跳槽到其他城市。

但是在我们开始讨论为什么我们选择Rust或者为什么它令人兴奋之前，我们为什么决定重写呢?传统的智慧告诉我们，当你已经有了可以运行的软件，甚至是部分可以运行的软件时，永远不要重写软件。但如果我们遵循这个逻辑，我们在未来的太空任务中仍然会运行阿波罗制导计算机软件(嘿，架构是1号的补充，但最后的错误报告是在1969年，所以它一定是可靠的)。为什么要重写呢?

简而言之，它归结为业务需求。

从架构上讲，现有的架构在没有大量工作的情况下无法扩展到其他技术或改变方向。由于许可成本问题，该公司刚刚被迫从另一家IaaS供应商转向了MQTT，而这一转变花了将近一年的时间。随着每年都有新设备发布(例如BLE、Wifi、Z-Wave、Zigbee、任意REST api)，企业希望能够快速改变物联网堆栈，以适应新技术。

有些技术性债务项目没有人理解，也没有人愿意解决。(我有没有提到过，最初的程序员都没有修复bug或回答问题?)在一个地方修复明显的问题往往会在完全不相关的代码部分破坏程序。

该程序有单元测试，但没有编码标准――某人的“非常聪明的”生成器表达式状态机驱动了串行帧协议，但它花了几周的时间才弄清楚它为什么坏了。

到处都是死代码，但我们不能证明那真的是死代码。

天哪，这些虫子。我有提到那些虫子吗?

有机会将容易出错的第一方Python Z-Wave处理程序代码替换为供应商提供的用C编写的参考实现。它将花费更多的精力来破解围绕C库的现有Python实现，而不是仅仅重写它。

我们想让更多的客户使用更便宜的硬件。提高这一比率将直接提高该业务的利润率。

因此，从这些业务需求中，我们可以开始为我们的特定项目挑选语言中的一些实际需求:

它需要与C语言对话并针对C库运行。

有定时要求(因为有串行通信)。

我们需要能够在土豆上运行它(因为成本)。

它必须能够同时运行串行通信和一堆命令/遥测，没有bug。

字符串操作应该很容易，因为命令和响应都是JSON。

软件必须正确和确定地工作，即使我们不是天才程序员。

它需要安全。

事实上，Rust符合所有这些需求。

我不会成为那些说每个人都必须使用我最喜欢的新语言的传道人之一。有很多很棒的工具，没有一种编程语言是完美的。事实上，Rust尖锐的学习曲线和接近裸金属使得它成为许多项目的次优工具。

为什么你可能不想用Rust

如果你需要快速创建原型，做面向webby用户的东西，有10亿个JS框架。如果你有足够的内存，现在的电子实际上是相当快的。

如果您需要快速创建原型，并且需要为科学计算数字，那么您可能需要Python。不要再在Matlab上浪费钱了，把你的助学金省下来给本科生吧。快点，暗能量不会自我解决的。

如果您试图在普通硬件上编写可线程的后端软件，如果您需要JVM库基础设施，可以考虑Go或Kotlin。

有时候一个shell脚本就可以了!

但是，如果你是一个和其他人一起编写代码的人，并且觉得你需要用C/ C++(速度、资源限制、时间限制、可移植性)编写新的代码，那么你应该强烈地考虑用“Rust”来编写它。

在下一章中，我将回顾一些我们不使用c++的原因，以及为什么Rust对我们有用。